1. Field of the Invention
The present invention relates generally to an improved data processing system and in particular to a method and apparatus for loading data. Still more particularly, the present invention relates to a computer implemented method, apparatus, data processing system, and computer usable program code for loading classes in a virtual machine.
2. Description of the Related Art
In a virtual machine, such as a Java™ Virtual Machine (JVM™), class loaders determine when a class should be loaded and where it should be loaded from. In a Java™ 2 Platform, Enterprise Edition (J2EE™) application server environment, each J2EE™ Connector Architecture (JCA) and application has its own class loader. The J2EE™ Connector Architecture is not able to access classes packaged in the application's archive (.ear module). Any dependent classes referenced by the J2EE™ Connector Architecture must be either packaged with the J2EE™ Connector Architecture archive (.rar module) or loaded by the parent class-loaders. If the J2EE™ Connector Architecture needs to access any of the application's classes, then those classes must also be packaged with the J2EE™ Connector Architecture. However, when the same classes are packaged with both the J2EE™ Connector Architecture and the application, there are class-loader issues for both sides:                If application-specific classes are passed into the J2EE™ Connector Architecture, then the J2EE™ Connector Architecture may not be able to interact with those classes. A NoClassDefFoundError exception would be thrown by the Java™ Virtual Machine.        If application-specific classes are returned by the J2EE™ Connector Architecture, the application may have a similar problem.        
This problem is due to the fact that Java™ Virtual Machine considers the same class loaded by two separate class loaders to have different class definitions. Since the J2EE™ Connector Architecture and the application are associated with different class loaders, exceptions will be thrown by the Java™ Virtual Machine when accessing, from either the application or the J2EE™ Connector Architecture, classes that are not loaded by a common, parent, class loader.
Current solutions package the dependent classes in a separate archive called a “.jar file”. The archive can be made available as a shared library or be loaded by the parent class loader by including the archive in its classpath. The drawback of this solution is that the application has to be repackaged into two parts: the application archive and the shared library. The application archive is no longer self-contained. In addition, the shared library is available to all applications deployed on the server. This availability of the shared library may be undesirable for some applications where the archive should not be exposed to other applications.